Hello, 各位 iT 邦幫忙 的粉絲們大家好~~~

這系列文源自這幾年在團隊裡導入 AI Coding 之後，一路踩雷、修正、再踩雷的真實過程。把這些收斂出來的方法整理成文，也許對正在煩惱同樣問題的你會有些幫助。

就當作是一份邊做邊記的工程筆記吧！

本篇是 當 AI 加入團隊：打造可審查、可驗證、會自我改善的 AI 開發工作流 系列文的 EP11。

knowledge/ 目錄一旦開了頭，很容易陷入一種誘惑。

把所有能想到的產品知識全部塞進去，變成一座百科全書。

我們刻意反著做——先從當前最頻繁、最常出現的情境開始累積，而不是追求一開始就完整。

第一批被寫進知識庫的，是團隊每週都會反覆遇到的幾種現場情境：某個裝置狀態異常的排查方式、某種常見告警的判讀邏輯、驗證裝置是否恢復正常的標準步驟。

每一篇都刻意寫得短、可定位，並且由一份 router 文件告訴 AI「什麼情況該載入哪一篇」。

<!-- knowledge/device-platform-a/README.md -->
# 裝置平台 A 知識路由

| 症狀關鍵字 | 對應知識文件 |
| --- | --- |
| 開機後服務未啟動 | ./service-not-starting.md |
| 韌體更新後版本回退 | ./firmware-rollback.md |
| 某告警持續觸發 | ./alert-loop-triage.md |

這份路由刻意寫得很薄：只告訴 AI「什麼症狀該讀哪一篇」，而不是一次把整個知識庫塞進上下文。

這個原則背後的判斷標準很單純：這件事會不會反覆消耗工程師的時間？它能不能被抽象成一組安全、可重複的判斷步驟？ 只有同時符合這兩點的內容，才值得被寫進知識庫；一次性的、只對單一裝置有效的細節，寧可先不寫，等真的再遇到第二次、第三次，才確定它值得被沉澱下來。

這加起來其實就一句話：知識庫不追求一開始就完整，只從會反覆消耗時間、又能變成安全可重複判斷的情境開始長。

知識庫從小處開始長，接下來就要處理另一件事：那些原本只存在遠端裝置操作裡的重複動作，要怎麼包裝成一顆可以直接被呼叫的技能？

下一篇見。